Guide for Reviewers
Public.icon
from Code review developer guide | eng-practices
What to expect from code review
What to expect from code review | eng-practices
Is the design appropriate for the system?
Should the code be changed or should the library be changed?
Is now the best time to add that feature?
Does the code perform the expected functionality or behavior and is it good for the code's users (other developers on the same team)?
Is the code concise?
Are accurate names used?
Are comments clear?
Comments should only explain "why" the code is necessary.
If it is necessary to explain "what" the code does, then the code is not concise.
Are there tests?
Quantitative and systematized quality control to evaluate behavior.
Code review speed
Code review speed | eng-practices
How fast should code review be done?
If there are no tasks in a state of concentration, code review should be done immediately after receiving the code to be reviewed.
The maximum time allowed to respond to a code review request is one business day. (In other words, it should be done at the beginning of the next day at the latest.)
Exceptions are made if you are working on your own task when a review request comes in.
Ideally, you should not have any reviews pending before leaving the office.
There is a concept of "LGTM with comments," which means "you can merge it if you fix only XX."
1. If the developer can appropriately address the issue themselves
2. If the issue is minor, such as having a "Nit tag"
How to write code review comments
How to write code review comments | eng-practices
Strike a balance between pointing out problems and providing clear direction while allowing the developer to make their own decisions.
["Generally, it is the responsibility of the developer, not the reviewer, to make changes to the CL."]
Developers, who are familiar with the code, have a higher potential to come up with excellent solutions. This is similar to Experts cannot manage in that Previous companies, interviews and appearances related to oneself.icon
How to Handle Pushback in Code Reviews
How to Handle Pushback in Code Reviews | eng-practices
Assuming that the developer has knowledge in the specialized field, the general guideline is Code Reviewer Guide for Developers | eng-practices#613088ed09c5f20000459c8a
However, reviewers often have a broader perspective of the features compared to the developers, so they have to explain the reasoning behind their suggestions
Code Review Standards
Code Review Standards | eng-practices
"Perfection" in code does not exist, only better code
What Reviewers should aim for is not perfection, but *continuous improvement.
Reviewers should always feel free to comment on areas where they feel that the code can be improved. However, if it is not a significant issue, add the keyword "Nit:" (which denotes a minor issue) at the beginning of the comment, and let Author know that they have the option to improve the code or not.
This is similar to Feedback and Review.Previous companies, interviews and appearances related to oneself.icon